1. Field of the Invention
The present invention relates to communication systems, and in particular, but not exclusively, to quality of service of data communications in a communication system.
2. Description of the Related Art
A communication system can be seen as a facility that enables communication sessions between two or more entities such as user equipment and/or other nodes associated with the communication system. The communication may comprise, for example, communication of voice, data, multimedia and so on. A user equipment may, for example, be provided with a two-way telephone call or multi-way conference call. A user equipment may also be provided with a connection to an application server (AS), for example a service provider server, thus enabling use of services provided by the application server.
A communication system typically operates in accordance with a given standard or specification which sets out what the various entities associated with the communication system are permitted to do and how that should be achieved. For example, the standard or specification may define if the user, or more precisely, user equipment is provided with a circuit switched service and/or a packet switched service. Communication protocols and/or parameters which shall be used for the connection may also be defined. In other words, a specific set of “rules” on which the communication can be based on needs to be defined to enable communication by means of the system.
Communication systems proving wireless communication for user equipment are known. An example of the wireless systems is the public land mobile network (PLMN). The PLMNs are typically based on cellular technology. In cellular systems, a base station (BS) or similar access entity of a radio access network serves wireless user equipment (UE) known also as mobile stations (MS) via a wireless interface between these entities. The communication on the wireless interface between the user equipment and the elements of the network can be based on an appropriate communication protocol. The operation of the base station apparatus and other elements of the radio access network required for the communication can be controlled by one or several control entities. The various control entities may be interconnected. A controller may be provided for each base station or a controller can control a plurality of base stations. Solutions wherein controllers are provided both in individual base stations and in the radio access network level for controlling a plurality of base stations are also known. It shall thus be appreciated that the name, location and number of the access network controllers depends on the system.
One or more gateway nodes may also be provided for connecting the mobile network to other networks, for example to a public switched telephone network (PSTN) and/or other communication networks such as an IP (Internet Protocol) and/or other packet switched data networks. For example, if a requested service is provided by a service provider located in other network, the service request is routed via the mobile network to the other network and then to the service provider.
The communication systems are continuously developed to allow introduction of new types of services, and to increase the efficiency of the communication systems. A project for such development is known as the third generation partnership project (3GPP).
Each communication system operates by running various different functions. For example, in communication environments such as those based on protocols such as the Internet Protocol (IP), the Session Initiation Protocol (SIP) and/or the current third generation (3G) communication network architectures various servers may be used for handling the provisioning of different communication services for users. In such communication systems the communication connections may not be based on a “circuit” between the communicating nodes, but the messages may rather be transported as packets that are provided with destination address information. Hence the name packet switched systems. The server entities and the user equipment may communicate with each other based on appropriate protocols providing such a connectionless operation.
The 3G Partnership Project (3GPP) is defining a reference architecture for the Universal Mobile Telecommunication System (UMTS) core network which will provide the users of UE (user equipment) with access to various services. Therefore the UMTS will be used in this specification as an example of a possible communication system enabling the communication services. Radio access is provided in the UMTS by means of a plurality of UMTS terrestrial radio access networks (UTRAN). Each UTRAN may employ a controller node that is referred to as a radio network controller (RNC). The UTRAN base stations are often referred to by the term NodeB.
The quality of service (QoS) is seen as one of the key concepts of the 3GPP UMTS in providing the level of service that users want for the service they use. QoS is believed to become even a more important issue when the traffic loads are increasing at the same time when more services are being made available for the users. In the IP network, the QoS attributes are mapped to standard Differentiated Services Code Point (DSCP) values. The DSCP values are transferred in the DSCP field of the IP header. The Differentiated Services Code Point value is provided in an IP header field of a packet to indicate the per hop behaviour (PHB) of the packet. The DSCP is used by routers to provide the correct quality of service (QoS) according to the defined traffic class.
The 3GPP specifications also specify the possibility of Internet Protocol (IP) based data transport in the radio access network between the network elements thereof, for example between nodes such as base station (e.g. the UTRAN NodeB), radio network controller (RNC), media gateway (MGW), and 3G serving GPRS support node (SGSN). However, the 3GPP only mandates use of the Differentiated Service (DiffServ) as a quality of service (QoS) mechanism for the IP based data transportation. This means that every UMTS terrestrial radio access network (UTRAN) node shall support the marking of the IP Differentiated Services Code Point (DSCP) values.
It has recently been discovered that the current way of signaling the IP connection information over UTRAN interfaces, i.e. between the radio access network nodes, might be problematic. For example, the connection information contains IP transport layer address and User Datagram Protocol (UDP) port numbers. The connection information does not contain any information regarding the quality of service on the transport network side, for example any information regarding the Transport Network Layer Quality Of Service (TNL-QoS). Despite this a requirement is that any bidirectional radio bearer provided by the access network such as the UTRAN is to have similar TNL-QoS treatment in both directions. This is irrespective of the transport technology used in the access network.
In 3GPP UTRAN it is assumed that the serving RNC is responsible for making decisions regarding the TNL-QoS. The originating UTRAN node has then the responsibility of marking the appropriate DSCP in the headers of those IP datagrams the originating node is transmitting, the originating node being the node that is transmitting the corresponding IP datagrams.
The present access network arrangements, however, are not able to guarantee that the access network nodes on either sides of a given interface understand the needed quality of service, such as the TNL-QOS, in a similar manner. For that reason it might be impossible to guarantee that for example the DSCP marked by a node is indeed such a DSCP that would result in the desired QoS in the transport network. This may become especially critical in the Iub interface between the RNC and the base station because the base station is not necessarily aware of those radio bearer parameters that are available for the RNC. Different access network controller nodes may have different logics. For example, it may be possible that a drift RNC has a different logic in determining the DSCP than a serving RNC.
It is also possible that different DiffServ domains are used. The term DiffServ domain is understood to refer to a part of the network or a network where common rules are in use for mapping a PHB to a DSCP. In another DiffServ domain these rules may be different. In that case a different DSCP would be required for the same PHB, as perceived by the datagram traversing the two domains. This may also cause problems.
Two alternative ways have been proposed to solve this problem in the 3GPP environments. In accordance with a proposal the required DiffServ Code Point (DSCP) that the peer node shall use is signalled on the Radio Network Layer (RNL) by means of an appropriate Application Protocol, for example by means of NBAP on Iub interface or RNSAP on Iur interface or RANAP on Iu interface. Another proposal has been to signal a generic, yet undefined, QoS information by means of the RNL Application Protocol so that the receiving node can then determine the appropriate DSCP based on that generic QoS information. Both of these proposals have problems, and therefore another solution might be desired.
Although the 1st proposal is fairly straightforward to implement, as the DSCP only needs to be passed down to the IP application and then the peer node (e.g. NodeB) may start using this DSCP. However, this alternative is not feasible in scenarios where there are more than one differentiated services domain between the RNC and the NodeB i.e. the base station. In that case the DSCPs corresponding to the per hop behaviour are expected to be different in different domains. The DSCPs of IP datagrams become mapped in the border routers between the domains, but the border routers do neither see nor interpret the RNL signalling messages that are sent between the RNC and the NodeB. Thus the DSCP that is conveyed by means of the RNL Application Protocol does not get converted along the route between the peer UTRAN nodes. Moreover, if the QoS mechanism in the network was based on something else than the DiffServ, this proposal would not be feasible at all.
The 2nd proposal might be problematic in that while it is expected to be feasible in all network environments, even in those where there is no DiffServ in use, it complicates the implementation both of the RNC and especially the NodeB. This is particularly true in those cases where DiffServ is used and only one DiffServ domain exists. If the “generic QoS” is used as the TNL-QOS info, both the Base station and the RNC need to have the additional capability to convert the generic QoS information to a DSCP.
Embodiments of the present invention aim to address one or several of the above problems.